Contemporary databases are built around the notion of table as the main structural unit of the storage space, designed to store in an organized manner relatively simple data, like numbers, symbols, strings etc. The table has a set of rows and columns, intersection of which forms cells, being the smallest storage units for storage and retrieval of actual data.
When the need arises to store in such a database more complex data, internal structure of which cannot be ignored during database operations, the most popular approach is to spread the complex data components over several table columns specially designated for this purpose. When warranted by the complexity of the data, additional tables can be created as required for accommodating all the data components and relations between them. Various implementations of this idea differ by the way the tables are created, columns are designated and data are spread over them etc., but table still remains the foundation on which the databases are built upon.
Such databases have gained widespread popularity due to a number of advantages they offer. They are built on a solid mathematical foundation, they are powerful and quick on the response to the data request, their size may vary from tiny personal database to a gigantic database, easily serving the needs of a big enterprise, and they are reliable and relatively simple in implementation. A detailed review of the database design can be found, e.g. in a textbook by Deen, S. M. “Fundamentals of Data Base Systems”, The Macmillan Press Ltd., 1977, or in a textbook by Date, C. J. “An Introduction to Database Systems” Volume II, Addison-Wesley Publishing Company, 1985.
However, it is getting more and more evident that some of their features, presumably considered as advantages, in many cases turn out being shortcomings. For example, with ever increasing complexity of data to be stored in the database, fitting complex data into a table quickly becomes awkward and cumbersome to achieve. A table lacks mechanisms for storing complex data, because it was not designed for this purpose. Another shortcoming shows up when there is a need to store data of variable complexity in the database. Normally, when designing a database, users have to decide how many tables is necessary to create, what columns should be in each table, what types of data will be put into them, etc. Unfortunately, in many cases, exact structure of the table(s), e.g. number of columns in the table, cannot be determined at the database design stage. It will be known only at run time, i.e. when the database is populated with actual data. For example, some columns of the table might be designated to store names of the authors of an article in a scientific journal. The actual number of authors is not known in advance, so the required number of columns in the table cannot be determined until the data entry begins, which is evidently too late. The fact that the number of authors can be different for different articles complicates the situation even further. At some point, the actual number of authors might exceed the number of columns designated for this purpose. As a result, some data should be dropped, or the database has to be redesigned and re-populated again if the complete list of authors needs to be maintained in the database. The above-mentioned example is just one illustration of numerous situations caused by the need of fitting complex data into a simple table structure.
Clearly, there is a need in the industry for the development of alternative database design principles and architecture, which would overcome the above-mentioned and other similar shortcomings of current databases.